The primary configuration settings for the SQL Server
Agent are located within the Object Explorer and SQL Server
Configuration Manager. Most of the settings that define how the SQL
Server Agent will execute are defined via the SQL Server Agent
Properties accessible from the Object Explorer. The SQL Server
Configuration Manager contains settings related to the SQL Server
Agent’s service. The service settings are limited but contain important
properties such as the Startup Account for the SQL Server Agent.
Configuring SQL Server Agent Properties
Figure 1 shows the SQL Server Agent Properties dialog that appears when you right-click and select Properties on the SQL Server Agent node located on the root of the Object Explorer tree.
You can set several
different types of properties in the SQL Server Agent Properties dialog.
The General options are displayed by default, and they include the
capability to set the auto
restart options and define an error log for the SQL Server Agent.
Selecting the option Auto Restart SQL Server Agent If It Stops
Unexpectedly is best for most installations. There is usually a heavy
dependency on the Agent performing its actions, and you probably want
the service to be restarted if it has been inadvertently stopped.
The Advanced page contains
options for event forwarding and idle CPU conditions. The idle CPU options define conditions related
to the execution of jobs that have been set up to run when the CPU is
idle. You can define idle CPU conditions such as the average CPU
percentage that the CPU must be below to be considered idle.
The Job System page has an
option to set the shutdown time-out interval. This option determines the
amount of time the SQL Server Agent waits for jobs to complete before
finalizing the shutdown process.
The Connection page includes an
option to set an alias for the local host server. This option is useful
if you cannot use the default connection properties for the local host
and need to define an alias instead.
The
History page options are related to the amount of job history that will
be retained. You have the option to limit the size of the job history
log and/or remove job history that is older than a set period of time.
Tip
Careful attention should be
given to the amount of history that is retained. Every time a job is
run, the history of that execution and the related detail is saved. The
need for careful monitoring is particularly true when dealing with SQL
Server instances that have a large number of databases. The msdb
database contains the job history records and can become sizable over
time if the history is not removed. For example, we have seen
environments where close to 700 databases were installed on one SQL
Server instance. The company was performing SQL Server log backups every
15 minutes on each of these databases and full backups each night. When
you do the math (4 log backups/hour * 700 databases = 2800
backups/hour), you can see that the amount of history written to the msdb database can be significant.
Configuring the SQL Server Agent Startup Account
The startup account
defines the Microsoft Windows account the SQL Server Agent service uses.
The selection of this account is critical in defining the level of
security that the SQL Server Agent will have. Access to resources on the
server on which SQL Server is running and access to network resources
are determined by the startup account. This selection is particularly
important in cases in which the SQL Server Agent needs to access
resources on other machines. Examples of network access that the SQL
Server Agent might need include jobs that write backups to a drive on
another machine and jobs that look for files found on other servers on
the network.
The startup account for the SQL
Server Agent is set initially during the installation of SQL Server,
but you can change it by using several different tools such as the
Windows Service Control Manager and SQL Server Configuration Manager.
The Windows Service Control Manager is a good tool for viewing all the
services on your server, but changes to the SQL Server services are
better made through the SQL Server Configuration Manager. The
Configuration Manager is more comprehensive and makes additional
configuration settings, such as Registry permissions, that ensure proper
operation.
The SQL Server Configuration
Manager is a consolidated tool that allows you to manage network options
and services related to SQL Server. To launch this tool, you select
Start, Microsoft SQL Server 2008, Configuration Tools. Figure 2
shows an example of the Configuration Manager with the SQL Server 2008
services selected for viewing. To change the startup account for the SQL
Server Agent, you can right-click on its service and select Properties.
The startup account used by the
SQL Server Agent is initially determined during the installation of SQL
Server. You have the option of choosing one of several built-in
accounts, or you can select a domain account. The built-in accounts are
available by default and do not require
any network administration to use them. These accounts, however, should
be used with caution because they can provide network access to the SQL
Server Agent that may not be desired. Generally, you want to provide
the minimum amount of security necessary for the SQL Server Agent to
perform its tasks.
The recommended startup
account for the SQL Server Agent is a Windows account. You specify a
Windows startup account for SQL Server Agent by using the This Account
option on the Service Properties window. The Windows account can be a
local user account or domain user account. It must be a member of the
SQL Server sysadmin fixed server role on
the local SQL Server instance. The use of this type of startup account
provides the most flexibility and allows you to tailor the network and
local resources that the SQL Server Agent has permission to access.
The Windows account does not have to be a member of the Windows administrators group. In fact, exclusion from the administrators
group is recommended in most cases. This approach adheres to the
principle of least privileges, which says that you should limit the
amount of security provided to only that which is needed. In many cases,
inclusion in the administrators group is not needed and only increases exposure to security threats.
The Windows account you
choose with the This Account option must have certain security rights to
be able to function as the startup account for SQL Server. The account
must have permission to log on as a service. You can set this permission
and others by using the Local Security Policy application, which can be
found under Administrative Tools. You can select the Local Policies node and then select User Rights Assignment
to display a list of all the security settings, including Log On as a
Service Policy. You should make sure the account you chose or the group
that it is in is included in this policy.
Tip
The Local Security Policy editor can be hard to find. In most operating systems, you can click Start Run then enter secpol.msc to launch the Local Security Policy editor.
Configuring Email Notification
The
SQL Server Agent can send email notifications; it can send email via
SQL Mail or Database Mail. SQL Mail was retained for backward
compatibility. It utilizes an Extended Messaging Application Programming
Interface (Extended MAPI) interface to send email and requires that you
install an email application (such as Outlook) that supports Extended
MAPI communication on the computer that is running SQL Server.
Database Mail, which is
now the recommended mail solution for the SQL Server Agent, is the focus
of this section. It was added in SQL Server 2005, and it utilizes
Simple Mail Transfer Protocol (SMTP) instead of Extended MAPI to send
mail. This simplifies email setup and has many benefits over SQL Mail,
including the following:
There is no requirement that an email client be installed on the SQL Server machine.
Email is queued for later delivery if the mail server stops or fails.
Multiple SMTP servers can be specified so that mail continues to be delivered in the event that one of the SMTP servers stops.
Database Mail is cluster aware.
Database Mail is disabled by
default in SQL Server 2008 but can be enabled using the Database Mail
Configuration Wizard. This wizard provides a comprehensive means for
configuring Database Mail. The Database Mail Configuration Wizard is not
launched from the SQL Server Agent node. Instead, you can launch it by expanding the Management
node, right-clicking Database Mail, and selecting Configure Database
Mail. This wizard guides you through the configuration of mail profiles,
SMTP accounts, and other options relevant to Database Mail.
After you set up Database
Mail and confirm that it is working properly, you can select it as your
mail system for the SQL Server Agent to send mail. You do this by
right-clicking the SQL Server Agent
node in the Object Explorer and selecting Properties. Then you select
the Alert System page in the SQL Server Agent Properties dialog, and the
screen shown in Figure 3
appears. In this figure, Database Mail is selected as the mail system,
along with a mail profile for Database Mail created with the Database
Mail Configuration Wizard. The mail profile you select can have multiple
SMTP accounts assigned to it. This allows for redundancy in the event
that the mail cannot be sent to one of the SMTP accounts.
To ensure proper functioning
of the alert system, you should restart the SQL Server Agent service
after the alert system has been configured. If you experience problems
sending notifications via the SQL Server Agent, you should check the
service account that SQL Server is running under. If the SQL Server
Agent is running with the local system account, resources outside the
SQL Server machine will be unavailable; this includes mail servers that
are on other machines. You should change the service account for the SQL
Server Agent to a domain account to resolve this issue.
SQL Server Agent Proxy Account
Proxy
accounts allow non–Transact-SQL (non–T-SQL) job steps to execute under a
specific security context. By default, only users in the sysadmin role can execute these job steps. Non-sysadmin
users can be assigned to a proxy account to allow them to run the
special job steps. In SQL Server 2000, a single proxy account was
provided for this function. With SQL Server 2008, multiple proxy
accounts can be established, each of which can be assigned to a
different SQL Server Agent subsystem.
To establish a proxy account for the SQL Server Agent, you must first create a credential. A credential
contains the authentication information necessary to connect to a
resource outside SQL Server. The credential is typically linked to a
Windows account that has the appropriate rights on the server. To create
a credential, you open the Security node in the Object Explorer, right-click the Credentials
node, and select New Credential. You give the credential a name, enter
an identity value that corresponds to a valid Windows account, and
provide a password for the account.
After creating a credential,
you can create a new proxy account and link it to the credential. To
create a new proxy account, you expand the SQL Server Agent node in the Object Explorer tree, right-click Proxies, and select New Proxy Account. Figure 16.4
shows an example of the New Proxy Account dialog. In this example, the
proxy name and credential name are the same, but they do not need to be.
The only subsystem selected for the sample proxy account in Figure 4 is the operating system, but a proxy account can be linked to multiple subsystems.
After a proxy account is created, a sysadmin can assign one or more SQL logins, msdb
roles, or server roles to the proxy. You do this by using the
Principals page of the New Proxy Account dialog. A proxy account can
have zero or many principals assigned to it. Conversely, a principal can
be assigned to many different proxies. Linking non-admin principals to
the proxy allows the principal to create job steps for subsystems that
have been assigned to the proxy.
Proxy accounts are
referenced within a SQL Server Agent job step. The General page of the
Job Step Properties dialog contains a Run As drop-down that lists valid
accounts or proxies that can be used to run the particular job step.
After you add a proxy account, you see it in this drop-down list. Keep
in mind that the account is not visible for a T-SQL job step that does
not utilize a proxy account. Steps that utilize the T-SQL subsystem
execute under the job owner’s context and they do not utilize a proxy
account.
